1. Field of the Invention
The present invention relates to a method and a system for storing a hierarchy in a relational database management system (RDBMS) used within a manufacturing execution system (MES). The hierarchy has a root element and is structured into branches with nodes. The method is carried out by a first process knowing the hierarchy and a second process storing branches in the database, and the second process receives commands from the first process.
In the world of process automation and process monitoring standard automation systems for controlling the widest conceivable variety of machines and plants are known in the prior art. Such technology covers in particular a broad range of products which are offered by the Siemens Corporation under its SIMATIC® product family within the field of manufacturing execution systems (MES). An extensive line of products for solving the technical tasks in question such as counting, measuring, positioning, motion control, closed-loop control and cam control enhance the performance capabilities of appropriate process controllers. A variety of configurations enable the implementation of flexible machine concepts.
Software programs can deal with and represent data in various ways. Nowadays the most popular of them are Object Oriented programming and relational databases. Many programs representing data as objects maintain objects “live” in memory, or in their process allocation space, mainly for performance reasons: in this way, in fact, objects are immediately available to processes, without the need of accessing a data storage component, as a relational database management system (RDBMS). On the contrary, RDBMS give a powerful way to make data persistent, and allow other software components to access them in a standard way. The set of objects living in the process allocation space (i.e.: directly available on physical memory) is usually referred as the process image.
In manufacturing execution systems (MES) software applications relational databases are broadly used not only to store data stemming from the production process, but also, and even more attributed, to store configuration data, application data and system data.
The process image of complex programs can be very complex as well, and objects there contained can be related to each other, forming a hierarchy, which can be of different types. In an MES environment a common hierarchy is the topological one, where a plant can be described by a set of objects which can, in turn, contain other objects of a lower level.
In many cases in MES applications we have to handle the persistence in a RDBMS of entities/objects hierarchies that are living in a process image managed using an Object Oriented Approach. One of these topological hierarchies is the plant model with all equipment defined for a plant according to the s95 standard levels, see ANSI/ISA-95.00.01-2000 Enterprise-Control System Integration Part 1: Models and Terminology. Each equipment instance is an entity with a standard attribute, a list of other equipment, methods and default values. Such equipment is inserted in a topological hierarchy, and thus it may contain other equipment, which in turn contains other and so on.
Storing an actual plant can require a lot of time because any equipment has to be sent to the database with a correct sequence, in order to create an effective and a correct hierarchy into the database tables. There, in fact, each item of equipment must be saved only when a superior one (i.e.: the one which contains it) has already been saved. Note that, in order to correctly store a plant it is necessary to store the relation with the parent node for any child equipment. It has to be noted that this problem relies also on the wide field of object-relational mapping (ORM), which is one of the tougher things to accomplish in modern, object-oriented programming languages.
In the state of the art (e.g. prior art), the question is how has this problem been solved up to now?
Usually this operation is made in an asynchronous way sending the object data in a queue. A dedicated process takes data from the queue and stores it in the database. The data have to be inserted, in the queue, in the correct order: first is the root entity then the first children level and so on. On the other side the process that stores data in a RDBMS has to proceed storing the root equipment and then the first children level of equipments storing also, for each child, the relation with the parent node. The correct ordering is guaranteed by the fact that:
The module where the hierarchy is defined is the one which inserts the equipment in queue, and thus can insert them in the correct order.
Elements in the queue are stored one by one; the subsequent element is stored only when the previous has been correctly stored, thus not altering the order.
The drawbacks of this approach are now described.
i) Since storing the equipment in RDBMS is an operation longer than inserting it in a queue, to avoid that it may grow indefinitely, speed of saving is ultimately determined by RDBMS.
ii) Additionally, to preserving ordering, the queue is unique and it is not possible to take advantage of multiprocessor hardware (HW), which is available now.
iii) The operation is not scalable.
Due to the above problems, this operation can be very time-consuming and ultimately unaffordable in case of a hierarchy with large structures to save. In such a case, downloading a plant model of medium complexity can require hours of work on the RDBMS side.